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(57) Abstract 

A system with a network interconnecting a server and a 
plurality of user stations. The ser/er stores a plurality of user 
applications for downloading to user stations and further stores 
access permissions for the applications for each user. When a user 
attempts lo log onto the system, the server uses the user's log-on 
identifier to build a list of applications for which the user has access 
permission. The server downloads to the station a list of applications 
to which the user has access pemiission. The user station uses 
the list to build a folder containing only the applications from the 
list to which the user has access pennission. The system further 
verifies from the list that the user has access to applications that 
are represented by objects that the user may have added to his or 
her desktop ai an earlier time. For each user desktop preference 
specified by the user ai an earlier time that corresponds to a user 
applicniion; the access pennission for the user to the user application 
is checked Irom the lisi. and, if the lapplicaiion is not included on 
the list, the desktop object representing the application is removed 
from the desktop. 
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CLIENT - SERVER SYSTEM FOR MAINTAINING A USER DESKTOP 
CONSISTENT WITH SERVER APPLICATION USER ACCESS PE RMISSIONS 

The invention relates generally to the fields of personal computing 
and networking. Specifically, it relates to the new and evolving field of 
network computing, in which desktop computer users use a personal 
computer, possibly diskless, connected to a network such as a corporate 
intranet, the Internet, or to an network or internet Service Provider 
(ISP) to gain access to applications which are then executed on the 
desktop computer. More specifically, the invention relates to 
server-based storage of software preferences (configuration data) for 
software retrieved from a server and executing at the desktop computer. 

The field of network computers is presently in its infancy.. 
However, it is expected to evolve rapidly, especially in the corporate 
environment, for a number of reasons. The expectation is that as 
companies and possibly individual users reach hardware and software 
upgrade points, it will be more efficient and less expensive to move to 
this new field, rather than upgrade in the traditional way with disk 
equipped computers and locally stored and administered software 
applications. For example, in the corporate environment, a user can be 
connected to a corporate intranet, using, for example, the TCP/IP and HTTP 
protocols of the Internet, and download software applications as they are 
needed directly from a network server to the des)ctop computer. An 
application is executed on the desktop in the traditional manner by the 
user to perform useful work. An advantage of this configuration is that 
network computers are substantially less expensive than traditional disk 
equipped computers. It might also cost less to purchase the required 
number of software licenses for users, rather than purchase individual 
copies of software for each user. Certainly, the software administration 
problems that attend large numbers of corporate users will be 
substantially reduced. At the present time, each user of a disk equipped 
computer or workstation often is effectively his or her own system 
administrator, a role that often consumes excessive resources due to lack 
of expertise. , It is expected to be c. greei adventege to eliminate this 
problem by effectively off leading the problem to a small number of server 
administration experts, rather than having many users struggle with the 
problems of software installation, upgrades and computer administration, 

AS mentioned above, this vision of the future of personal computing 
is presently in its infancy. As a result, there are presently many 
problems and deficiencies with existing systems. 
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Typically, in network computer systems, an administrator creates 
user profiles that are stored on a network server. The profiles may 
contain different types of information, such as user desktop preferences 
and user permissions for access to different software applications that 
5 might reside on the server, when a user logs onto the system, the user 

identifies him or herself to the server, the server locates the profile • 
for the user and transmits it to the user computer whdre it is used to 
configure the computer and generate a desktop. The desktop might include 
a number of icons representing applications to which the user presumably 
10 has access. The profile likely also contains other attributes of the 

computer and desktop, such as for example, the background colour of the 
desktop, or character fonts and point sizes used on the desktop, or data 
file search paths, etc. that are unique to the user. The profiles may be 
user modifiable or non-modifiable. 

15 

In an environment in which users can modify their own profiles, a 
modified profile is uploaded back to the server at log-off time, where it 
is stored for retrieval the next time the user logs -on. In some prior art 
systems, to the best of our knowledge, the users can generate on their 

20 desktops any configuration of application icons they wish, whether or not 

they exist on the server, and whether or not a user actually has access 
permission to an application on the server. The Lotus Workplace Desktop 
(previously called Kona Desktop) system is an example of this type of 
operation. In other systems, the server presents a list to the user of 

25 all applications that the server has, from which the user can pick. In 

this case, there is no guarantee that the user actually has access 
permission to an application that is selected from the list for inclusion 
on the desktop. The Sun Hot Java Views system is an example of this type 
of system. In other words, the prior art systems do not correlate between 

30 what the user can configure for the set of desktop application icons and 

applications to which the user actually has permission access. In such a 
case, when the user clicks on a icon to execute an application, an error 
messaqe may occur (such as an unauthorized access message) if access 
permission is not present, or in a worse case, the user's computer may 

3 5 crash. 

Another limitation with existing art is that a flat data structure 
is used to model users, user croups, terminals and groups of terminals. 
Modeled after a common scheme for managing user access to computer 

40 resources, known network computer implementations (e.g., Lotus 

Administration [Facility for Desktops, Microsoft Windows NT Profiles and 
Policies, and Sun Hot Java Views) implement a flat 'groups' structure on 
the server for managing software preferences (or attributes) in various 
contexts. A 'context', as used here, refers to an individual user, user 

45 group, terminal, or terminal group. Any grouping structure for 
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managing software preferences on the server allows an administrator to 
define preference attributes for different groups of users as well as for 
individual users. However, flat systems are inflexible' in many 
environments, especially in environments having large numbers of users. 
It is desirable to provide an administrative tool supporting the 
organization of preference information into a hierarchical structure. 

Another limitation with existing systems is that they are limited in 
the ways that administrators and users have to perform user configuration 
of workstation desktops. For example, administrators are presently 
required to- configure user preferences using configuration programs that 
are separate from, but associated with, a user application. It is 
desirable to allow vendors to provide only a single application. To 
require only an end user application from a vendor necessitates that the 
central management facility be able to execute the end user application in 
a context of a user or user group. The prior art does not allow this 
administrative flexibility of operation. in other words, in the prior 
art, to the best of our knowledge, an administrator does not have the 
ability to run a user application in the context of a user to set 
preferences for that user and application. Further, in the art, an 
administrator cannot run a user application to set preferences in the 
context of a group of users. 

Still another limitation in the prior art known to the inventors is 
the manner in which the prior art partitions server permanent storage 
space to guarantee that a unique space is reserved for storing user 
preferences related to the different applications on the server. To the 
knowledge of the inventors, the problem of preventing collisions in the 
storage of preference information for different applications in 
object-oriented systems, in which an object can be queried for its fully 
qualified class name which uniquely identifies and differentiates it from 

classes, is solved by having a first central authority assign a 
unique designation that applies to a vendor and by then having a second 
authority at the vendor assign a second designation relative to the first 
designation for each vendor application. For example, vendor A might be 
assignee the designation vendorA by the first authority and that 
designation is guaranteed to be unique within the architecture for which 
the first authority is acting. The second authority at vendor A then 
assigns the second designation for each of its applications within that 
architecture. For example, one of vendor A' s applications might be 
designated— vendorA.Appl; another might be designated vendorA. App2 . The 
art maps the unique designation for each application in a system to a 
location in permanent storage of the system to guarantee that preference 
data for the different applications do not collide in storage. An 
application, when running, informs the network computer server of its 



wo 99/57863 PCT/GB98/03866 



unique storage location and it is the responsibility of the server to 
partition an area at the starting location according to a context (user, 
user group, terminal or terminal group) for storing preference 
information so as not to collide with preference information in a 
5 different context. Clearly, this manner of administering storage space is 

awkward and undesirable. It is desirable to devise a method to 
automatically generate unique storage locations for storing preference 
information for the afore mentioned object-oriented applications, without 
resorting to the requirement of having central authorities assign unique 
10 designations for the purpose of preventing collisions in the storage of 

preference information and without coding storage location information 
into an application. 

Still another limitation in the art lies in the lack of any 
15 provision to migrate existing applications and hardware into the new 

environment of the centrally managed network computing world without 
requiring changes to the existing hardware and applications. Existing 
hardware, a terminal for example, in a networked environment, gets its 
configuration information at boot -up time from a file in a specific format 
20 located on a server. The terminal is programmed to know how to access its 

configuration file. The terminal uses a unique identifier to access the 
file from the server. The unique identifier is often the media access 
control (MAC) address of the terminal. However, in a new centrally 
managed environment involving protocols and API's that are different from 
25 that to which the terminal is designed, the terminal cannot access 

preference information in the new environment, the terminal can only 
access its configuration file in the way for which it is designed- This 
is a serious problem, because there are many such existing devices in use. 
The inability to use them in new systems impedes substantially the 
30 incentives for users to migrate to the new systems. 

Still another limitation in the prior art concerns the interface 

between an administrator and the configuration management system. When 
configuring software within an administration facility to configure 

35 preference information for various users and user groups, and terminals 

and terminal groups, the administration software launches in the context 
(user, user group, terminal or terirnnaj group) set by the Administrator 
who is running the facility, when the Administrator changes the context 
that the application is running under, the application needs to be 

4 0 relaunched to load configuration information for the new context. The 

process of relaunching software each time a context is changed is time 
consuming and inconvenient for an administrator, especially in systems 
with many users. In such systems, it is expected that an administrator 
will change contexts many times while configuring an application. 

45 
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According to one aspect, the invention provides, in a network system 
comprising a network interconnecting a server and a plurality of user 
stations, a method of managing desktops on the user stations from the 
server, wherein the server stores a plurality of user applications for 
downloading to user stations, and further stores access permissions for 
the applications for each user, said method comprising steps of: receiving 
at the server a log-on request including a user identifier from a user 
station; using the identifier to build a list of applications for which 
the user has access permission; downloading to the station the list of 
applications for which the user has access permissions; and displaying on 
a portion of the desktop objects corresponding to each application in the 
list, said objects when selected by the user being operative to request a 
download of the corresponding application to the user station. 

According to a second aspect, the invention provides, in a network 
system comprising a network interconnecting a server and a plurality of 
user stations, an apparatus for managing desktops on the user stations 
from the server, said apparatus comprising: means for receiving at the 
server a log-on request including a user identifier from a user station; 
means for using the identifier to build a list of applications for which 
the user has access permission; means for downloading to the station the 
list of applications for which the user has access permissions; and means 
for displaying on a portion of the desktop objects corresponding to each 
application in the list, said objects when selected by the user being 
operative to request a download of the corresponding application to the 
user station. 

According to a third aspect, the invention provides a computer 
program product stored in a computer readable storage medium for, when run 
on a computer, carrying out in a network system comprising a network 
interconnecting a server and a plurality of user stations, a method of 
managing desktops on the user stations from the server, wherein the server 
stores a plurality of user applications for downloading to user stations, 
and further stores access permissions for the applications for each user, 
said method comprising steps of: receiving at the server a log -on request 
includinc a user identifier from a user station; usinc the identifier to 
build a list of applications for which the user has access permission; 
downloading to the station the list of applications for which the user has 
access permissions; and displaying on a portion of the desktop objects 
corresponding to each application in the list, said objects when selected 
by the user being operative to request a download of the corresponding 
application to the user station. 

The system described herein provides a common repository for 
configuration information for users and applets in a client- server 
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or.^ This is referred to as client profile management. The 
L ro... .... is. .o ^o.... .^o. - .^e 

system at any ti.e and have it configured automatically at run tx^e 
acrording to the preferences stored for the user at the server. The 
preferred en>bodin.ent is a aava (aava is a Trademark of Sun. ^nc.) basea 

^ste"-- — ' dTent" user ' 

^^r^^i-^r,r^cL Thus, in the preferred embodiment , user 

ZlZi: r r d::r;appre: ire assumed to .e .ava applets However, 
it is not intended to limit the invention to a aava — — ^/^^^ 
pre erences for the locally stored applications mi.ht be stored locally xn 
Te traaitional manner, while preferences for the server-based applets 
might be handled in the way described herein. 

The invention solves the problem whereby a user is able " ."^^^^"^^ 
>.is or her desktop so as presumably to be able to access an applxcatxon on 
hxs or her oesK p ^^^^ ^^^^^^ permissxon to 

<-Vie server when, m race, i-iie "^'^ „eo-r 
.l.e application, when the user logs onto the system, the user 

iuild a portion of the desktop, preferably a desktop folder, of 

buxld a P°^"° ^^^333 permission. Preferably, the 

applications to which the user .^^^^ ^^^^ ,^^,1, 

fr»lder is composed of a numner ox c^yh^ 

correspond to a different application and which may be selected by the 
correspond ,33,ciated application. Associated with each 

,3er to launcb the p,,,,3,,,3 necessary for the user to execute 

applxcation in P ^^^^ parameter might be the 

.ne associateo application. Nothing prevents a 

URL on the server used to invoke tne pp desktop is built, 

^•i: ir,« »-v.o flpsktot). For example, after tne aet.ri.tufc' 
user from modifying the desktop, r • the desktop, even 

the use. c.„ 'f ^-^^^^^^ ""^'1 ^Mo. Cse »i,.t 

..o„,. "=.>a not --^^ J:-, ,3 .^^.caxl, ,enex.«. 

„ Z::T:jZ lTJZT:o,..r to .no..er P=rt Of the aes.top and 

! Lrthe user .c,s off, or otherwise s.ves his or her 
then lo,s o£.^ ^f.^^^.^^ „ethoa the system «i9ht provide, the 

preferences "'f'"^ server' .na becomes pert of the preferences 

„piea .con .s aveo to the^s ^^^^ ^^^^^ ^^^^ ^^^^^^ 

configured for the user. - v. ^ r,^^ nart of the automatically 

copied icon is reproduced on the oesktop. not as part of th ^ 

iHc^ Of accessible applications, but Dust as part of the 

= \rr t^efch- ^^^^^^^^^ 

"T/aiL/rUucatlcn permissions present on the server. « e 
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user has included an application object on the desktop to which he or she 
does not have access permission, then the object is automatically excluded 
from the desktop object that is built by the server at log on time. 

In a preferred embodiment comprising a system with a network 
interconnecting a server and a plurality of user stations, the server 
stores a plurality of user applications for downloading to user stations 
and further stores access permissions for the applications for each user. 
When a user attempts to log onto the system from a user station, the 
server receives a user log-on identifier from the user. The server uses 
the identifier to build a list of applications for which the user has 
access permission. A desktop object is then downloaded to the user 
station to control the interface between the user and the user's station. 
The server also downloads to the station a list of applications to which 
the user has access permission. The user station uses the list to build a 
folder containing only the applications from the list to which the user 
has access permission. The system further verifies that the user has 
access to applications that are represented by icons that the user may 
have added to his or her desktop at an earlier time. For each user 
desktop preference specified by the user at an earlier time that 
corresponds to a user application, the access permission for the user to 
the user application is checked from the list, and, if the application is 
not included on the list, the desktop object representing the application 
is removed from the desktop. 

Fig. 1 shows an illustrative network and user stations, including an 
administrator's station, in which the invention might be practised; 

Fig. 2 shows an illustrative block diagram form of the 
administrator's station in communication with a server, and components of 
the administrator's station and the server for providing the central 
profile maneaement and preference administration; 

Fig. 5 shows one illustrative hierarchical organization of user 
groups and users of a system. The illustrative hierarchical organization 
might also contain individual ter-p.lneis and terminai croups; howevei , 
these are omitted for simplicity; 

Fig. 4 shows one illustrative listing of individual users and the 
group priority order that is used to determine a set of preferences from 
the hierarchical organization of Fig. 3 that apply to a user and a 
specific application executed by the user; . 

Fig. 5 shows a more detailed view of the administrator's station and 
server of Fig. 2; 
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Fig 6 Shows an illustrative view of the software objects at a 
user's te^nninal. including a user application and the API between the 
acolicati^ and other components, that cooperate to establish the user 
^reierences during execution of the application as the user's ter.xnal; 

Figs. 7 through 8 show illustrative operations at both a user's 
...minal and a server for user log-on and initially establishing the 
Te^^s de^Ktop, including desktop preferences, at the user ter^xnal; 

Figs 9 through 11 show illustrative operations at both an 
administrator's terminal and a server for administrator user log-on. 
^abiis^ent of the administrator's desktop, and. by way of example, the 
establishment o ^^^^^^^ configuration; the example 

:rrrirustrates Tc^text change during configuration the user's desktop 

and the resulting operations; and 

Figs 12 through 24 show a variety of actual administrator screen 
snapshots In various phases of application administration, xncludxng 
r if no of a hierarchy of which Fig. 3 is a representation of an 
buxld ng of a J ^^^^^^^^ ,3,,,, establishment of 

rp::!catro; "e^erences for applications, and context changes during 
preference establishment. 

The system described herein provides a common repository for 

.^r!!formation for all users and applets in a client- server 
configuration Z^^^^^ ,,,,,, p,o,ile management. The 

^^rteraUows us'ers to roam, that is, to log-in from any computer in the 

Z at any time and have it configured automatically at run txme 
system at ^J'J ^'^l^^^^^^^^^^ 3,,,,, 3t the server. The preferred 
according to the prefer ^^^,^^,,y, sun. Inc.) based system and 

T~ c™ . ... .^owser interface arranged to execute Oava 

programs . 

The terms 'applet' and 'servlet' are established terms in the 3ava 
1 ncuaoe art and will be used herein, since the terms have 
^^°^"To'thrse ed in this art. '.PPlet' refers to an independent 

meaning to J^^^' ^.^^^^^ ^ ^eb browser. Servlet 

SrtoT t::: Td^le that resides on a aava enabled web server. I 
is .0 be understood that the use of the terms 'applet' and 'se.rvlet 
r not intended to limit the invention in any way. For 

to . software »oaul. usea to configure preferences for an =,a user 

/ auction such as a wora processor, a database manager, etc. 

"r: a:;Ucat.ons .re ..so .applets, in the o.v. environment. 
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the phrase 'user applet' or just 'applet' is used herein to refer to an 
end user application. \ 

In' the preferred embodiment , user applets and the desktop applet 
are assumed to be Java applets. However, it is understood that the 
invention is not limited to a Java environment. The invention can be 
used in any client-server system. For example, if desired, the system 
could be designed to use proprietary communication protocols and 
applications written and compiled in any desired programming language. 
Further, even in the preferred Java based environment, disk-based 
computers might access some applications locally, and other applets from 
the server. Preferences for the locally stored applications might be 
stored locally in the traditional manner, while preferences for the 
server-based applets might be handled in the way described herein. 
Preferably, however, preferences for locally stored applications are 
stored on the server using the Profile Management Properties API in 
addition to the preferences for server based applets described herein. 

A simple Application Program interface (API) allows applets written 
to the API to easily store and retrieve preference data when the applet is 
executed by a user or administrator. Applet permissions and user 
preferences can be defined based on group memberships and individual 
identity. 

Client profile management includes the following services: 
Log-on support - mapping to a user profile; 

User support - the administrative ability to create user identifications 
and provide services and preferences directly to users; 

User groups support - the administrative ability to create hierarchical 
groups of users and provide services and preferences based on group 
memberships ; 

User eppiet context transparency - outomatic determination of the context 
of user applet execution. That is, the determination of the user and/or 
group profiles that apply to a user applet execution and the automatic 
establishment of the profile environment; 

User applet preferences repository - context-sensitive server storage for 
user applet configuration data; 
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of inheritance; and 

_ ..e. ... c.„c. : — ^ "-ZJ^-T^ . 

for individual users. 

...nt nrovides a framework through which these tasks 
'":r;Tasks are supported by profile .anagen^ent directly, 
are performed, some "^^^ ..^^^^ ^^^,ext switching, preference 

e.g. user/group ^^^^^^^I'^X^ -rvices specific to user applets 
inheritance, ^^^^^ l^^^J^^^ configuration applets invoked by a 

are usually supported ^VJJ^ :.anagement environment. 

some end user applets mxght p administrator can run 

- the end -- --- . ^pofe ^o ateparatL configuration applet) in the 
To^rt rinrv-aLrLers ana groups to set the configuration 
preferences for those users and groups. 

a-n intendea environment for 

plurality of user stations, computers), an 

.a»inlstta.or.. station 108 ana a e«boai».nt, network 100 

100 »i,ht be a local area net^orK^ m « „ corporation, that 

„l,ht include »>ae ar.a '"re still incl.d.a within the 

-ve — ^""i^Jtrtir ; il "vlron^ent in which the 

syste.. inaeea, = network o. any tvpe that 

invention ...ht oe pract ^^^^ ,„vulonea. 

interconnects many types 

profile management administrative 
^ ^l,n-level '^^ " ^ aa»inistr.tor client network 

operating environment iS shown " ^^rver 202 tor 

computer 200 is represented "^J^^^^-^ „»„nic.te via a 

.he syste„ is on the ri,h . The ^ assumes that 

network representea as J^^;^^„,,„.„,, , computer, 
the client computer is a syste 

' 206 on the client side allows the administrator to 

profile manager ^06 - ^ ^^^^ ,,,,p levels. The 

configure --//^ J^/J/^r^sers and group hierarchies, add users to 
administrator can create p„,,,3i.o:....._for....ph.grppp and for .. 

different_.groups, ^^'^^ Z.^,^tr..or can configure applets xn the 
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context of an individual user or a croup. The administrator can add, 
delete and reset passwords for users. Profile management support is 
transparent to the general user. The administrator can 'invoke the profile 
manager 206 in the context of any user or group. Only the administrator 
can change from his/her context to administer clients (users) and groups. 
The server will not allow a user without administrative authority to 
switch context. when a request comes into the server, it will query the 
authenticated ID of the user trying to access this function. If the user 
does not possess administrative authority, (i.e., is not a member of the 
AllUsers-Administrator group), the Profile Manager Servlet 214 will 
reject the request. 

Profile manager 206 invokes other applets, such as appletl (208), as 
shown in Fig. 2. In this example, appletl might be the administrative 
applet for configuring preferences related to user desktops. Or appletl 
could be a configuration utility related to an end user applet, such as 
editors, word processors, databases, etc. It is preferred, but not 
required, that configuration applets such as 208 exist as modules separate 
from their corresponding user applets. In the context of Fig. 2, Appletl 
is typically a configuration applet for a user applet; the administrator 
runs the configuration applet appletl under a group context to set group 
preference and permission defaults, or in a user context to customize user 
applet configurations for an individual. By implementing appletl as a 
module separate from its user applet, performance is enhanced, since the 
configuration appletl will likely be small compared to the user applet. 
Also, separate configuration applets allow the administrator to control 
the end users ability to configure the user applet. 

Traditional stand-alone computers store user applet configuration 
information locally in association with its the user applet. Traditional 
stand-alone Java based computers store user applet configuration 
information using the format provided by the java.util. Properties class. 
Both arrangements require that the user applet specify the name of a local 
file in which to store configuration information related to the user 
applet. In other words, a relationship is required between the computer 
and the user applet loaded on it. Profile management as described herein 
provides the familiar capabilities of a real java.util . Properties object 
plus additional facilities supporting user -roaming capabilities and 
seamless pluggability into a powerful administrative framework (the 
Profile Manager) . 

Prof ileManagementProperties P 210 is a properties object for appletl 
and provides an API between Appletl and the server that allows the server 
to determine where to store configuration information for appletl in the 
context of users and groups. The Prof ileManagementProperties object class 
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r *.v^o ^^^P^ ntil. properties class with 
•^oc all Of the functionality of the Dava.utii.pxup 
provxoes all Of ^^^^^^^ ^^^^^ 

the further ability software from permanent storage. Storing 

configurations possible. .„,,r^;,ror Prof ileManagementProperties • 

When a user is in the role of "^Z/^^^;/;;,, applet corresponding to 

210 allows the aa^inistrator to ^^^f " ^^^J^jrappLtl is an end user 

, :re^"rU conte.t. ^^i:::-^-: ^^.^ 

^plationship between the oser applet ana the user, 
"et p"« .na co^oter i,> ttaaitional -ste^s 

:„.neHana,e„entPtope.t.es ^l^^l-^^.Z:'.^^^^^^'^''^ P-" 
java.utll. properties class, ■me e»tensi ^^o^^i.tea "1th . key, 

5 preference infonuation o£ a """""^ J^^^'/^^'.iL. «,is, in turn, 

'as cpposea tc a stream, as ""^J^;;:^^ ^Uifv a unique location 
appucaticn ev oper to^use the^^.^^^_^^ ^^^^^^ ^ _ 
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ana path. '"""""'T/ "/xe",: aiscossea .™=re in connection 

, aut^ticaU.. The -7;-»,::;;:„,I,e„„a,e„entProperties =10 a.ter 
with F>g.-s e ana '■ J' „n take aavanta,e of 

the java.util. properties class, the Si evaluation. Thus, 

preference inheritance through ^2,11". capability by accu»ul.tin, 

tnis -:::;'arrrre rro^t::::":: ais:ussea „ith respect to 

" IZTZI IZ.TL:\. the contextual hierarchy for aef aults . 

0T5 t-nat Stores user data and group 
server 202 includes a database 212 ^J^^^ 
aata, such as user and group preferences ^^ ^^^^ ^^^^^^ ,,,, support 

• » wpt^server 218 represents a typical 
30 permissions. Webserver 2 ^^^^ ^^^^ ^^^^p 

TfLrtir to rererrra. it also maintains an access control 
to^ra:::: user access to applications on the server. 

.^^^A PC, a tree hierarchy, as shown 
„ser ana .roup preference, are ^["'l^l^^^Z.^^, the top group 
in n,. 3. Ml us«s Of the ---^^^^^f;;:;^^/,, this group contains the 
MLsers. «l "er aPP-" - " 

aefault P"'"!-:^;;:,n:r:L .ont ins at least three user applets, 
3, it is assumed that the server ,„.._=ted in the AllUsers group. 

,0 identified as .,p3. .PP4 and .pp5 ^^^^^f^^ ^ ,,,,, illustrative 

the default background (BG) ^^/f^^ ^^^^ ^^have the default values of 
preferences labelled as x, y and z are shown ^^^^^ represent 
and 3 respectively. The "rms x y and z a ^^^^ 
^ v'Ko values 1j ^ ana -> 
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merely to Illustrate the point. The x preferen 
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screen font for the desktop; the value x 1 might call for a default font 
of Times -Roman, Similarly, the default preferences for»App4 for all users 
are BG = grey, x = 2, y = 2 and z = 2. . * 

The default values in the AllUsers group can be modified in any 
desired way for other contexts, such as for other user groups and 
individual users. By way of example, in addition to the context of 
AllUsers in Fig. 3, four other groups (Groupx, GroupY, GroupYl and 
GroupY2) are shown. Additionally, two individuals Userl and UserN are 
shown- Users can be members of more than one group. In Fig. 3, Userl is 
a member of AllUsers, GroupX and GroupYl; UsenN is a member of AllUsers 
and GroupY2. If a user is a member of more than one group (another group 
in addition to AllUsers), then the groups are prioritized for the purpose 
of selecting the preferences for a given applet for that user. The 
administrator configures the group priorities for a user. Group priority 
is illustrated in Fig.. 4. ' In Fig. 4, Userl has GroupX (identified by the 
fully qualified name of AllUsers . GroupX for his or her highest priority 
group. Userl 's next highest priority group is GroupYl 

( AllUsers.GroupY. GroupYl ) . Userl's lowest priority group is the AllUsers 
group- When a user, say Userl, requests to run an applet say App3, the 
preferences are coalesced from the tree of Fig. 3 according to the group 
or groups to which the user belongs and the user applet is configured on 
the user desktop accordingly. 

The first step in coalescing preferences for any context is to get the 
defaults. The defaults for a user, if there are any, is the coalesced 
set of preferences for the applet from the highest priority group from 
which preference information for the applet can be obtained. The defaults 
for a group, if there are any, is the coalesced set of preferences for the 
applet from the groups parent (i.e.. The AllUsers group is the parent of 
AllUsers. GroupX) . If a group has no parent (i.e., the top level AllUsers 
group) , there are no defaults for that group. To coalesce the preferences 
for an applet at a context, the preferences for the applet explicitly 
stored at the context, overwrite the default preferences for the applet 
for the context. Thus, to coalesce preferences into the default set for 
an applet in e aroup context, recursive calls are made from each group 
node up to the AllUsers group requesting each parents set of preferences 
for the applet. Please refer to figure 3 to illustrate the forilowing 
example. For example, if the context is Allusers .GroupY .GroupYl , a call is 
made to the parent of GroupYl, which is GroupY, requesting its default 
preferences for the applet. GroupYl makes a recursive call to its parent, 
which is AllUsers. AllUsers has no parent, so AllUsers returns it set of 
preferences for the applet to the call from GroupY, This set of 
preferences is modified by the preferences stored in GroupY for the 
applet, if any. This is now the default set of preferences for the applet 
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become the -'^-^/J^ J^^^^ , ,3,, is built in the sa^e way. except 
' "rr^r^est "o^it™ ..o. Which preference information can .e - 

T Zl for the user is used to first establish the group context from 
rthe a f obtained. Then the recursive proceaure 

Tscribed above is used to buiia the actual set of preferences for the 
10 user and the applet requested by the user. 

^■1^= -innstrate the above preference coalescence 
The following examples illustrate 

and should be read in conjunction with Fig. 3. 

Example 1: An administrator runs a configuration applet fox .pp3 to 
set preferences for the group Aliusers . GroupX. 

TO set the preferences for App3 in the context of Allusers .GroupX. 
TO set the p determined. AllUsers -GroupX 

the present set of preferences AllUsers is the top 

,0 requests defaults for ^ ^^i"-/ ^^^fto OroupX. These are the 

,evel group it retu s -J since GroupX has 

aefault ^^f^ 3et from Allusers is the real set of 

no preferences f or App3 , . these preferences from the 

preferences to be ^'^t' ^^^J"" ,=3. administrator can now 

" rod::r:srre ToL igurtLn- applet to modify the coalesced preferences in 
any desired manner. 

^^.e 2: userl ,«.e.t. e.ecu.ion c£ C<».ib».«p3. Preferences 
„ „os. be coaxesced i.r =c„.ibm.«.p3 1. the context of ose.l. 

Fi, 4 sho»s that the highest priority group tor userl is 
Fig. sno , „ro„p hierarchy will be checked first 

AllUsers. Groupx; this branch of the . P example 

for preference i„fo™=tio„ -""-'-^^^J^^^ ^^^t.^the coalesc.a set 
3= is essentially the s.„e as 3 workstation. The 

of preferences is .sea to con igure "PP ""^ ^.3 ^,„<,. 

preferences for .pp3 -^^^JJ.^rr.rtlxt f;r .pp3 over riaes the 

rer.:::Vo:ri:rrr:f:rre ^tlLa ..^ the .nusers.cro^px branch Of the 

4 0 preference tree.i 

Example 3^ Coalescing preferences for com.ibm.App6 in the context of 

Userl. 
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This example illustrates the situation of the highest priority group 
containing no coalesced preferences for the context of OJserl . Again, the 
highest priority group for Userl is GroupX. This group! and its parent 
AllUsers contain no preferences for App6. Therefore, the next highest 
5 priority group is searched. The next highest priority group for Userl is 

GroupYl. A set of preferences can be obtained from this group for App6. • 
The coalescence of preferences proceeds es described in example 1. 
Recursive calls are made from GroupYl up the tree to the root AllUsers 
group and the preference sets are returned back down the recursive calls 

10 and modified along the way to form the default set. The default set is 

then modified with the preferences stored in GroupYl to form the 
coalesced set of preferences that apply to this context. Stated briefly, 
Allusers returns a null set of preferences, since it has no preferences 
for App6. GroupY modifies this null set with the values a=l and b=2 £uad 

15 returns this set to GroupYl as the default set. GroupYl modifies the 

default set with a =33. This set is returned to the Userl context for use 
as its default set. Since there are no preferences for App6 stored at the 
userl context, the defaults obtained from the GroupYl branch of the 
preference tree represent the fully coalesced set of preferences for App6. 

20 The real set of preferences thus becomes a=33, b=2 for this context. 

The above 3 examples described the gathering of preferences in 
response to a loadO for a particular piece of software, when preference 
information is saved for a piece of software, any preferences that have 
25 been explicitly written at the Context being saved to will be written to 

the data store (212) at the location specified by the combination of the 
Context the software is being run in and the key for the software whose 
preferences are being stored. 

30 Permissions operate similarly: a new group has access to all the 

applet names permitted by the group itself as well as to all applets 
permitted by its supergroups. However, just as Java allows the programmer 
to override a superclass method, Profile Management allows the System 
Administrator the ability to override an inherited permission. This is 

35 called overriding a permission. 

AS with Java's form of inheritance. Profile Management's form of 
preferences and permissions inheritance is called single inheritance. 
Single inheritance means that each Profile Management group can have only 
40 one supergroup (although any given supergroup can have multiple 

subgroups) . 

Profile Management users (leaf nodes) may require membership in 
multiple groups, so a facility is required to limit preference inheritance 
45 to a single hierarchical group to minimize the chance of corrupt 
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.prions due to the introduction of incompatible variable subsets 
'" rr/bv cross croup branch coalescing. By allowing a user's group 
.ntroducea by cross P management can follow a search 

"'"^"tln licking for preferences related to a particular applet, xn 
order when looxing loi v v*„v,p=t oriority, the search 

J, c*a-ri-ina with the group with the highest pTiui-i^y. 
5 other words, starting witn t y „„„f i auration data for the ■ 

will stop at the first group found to contain configuration 
applet attenipting to load its preferences. 

. inherits software permissions from group memberships. With 
:nrer;r!e model ing, the administrator can assign software access 
10 careful --"^^^^^^ ^ ,,,ig,,e through panels, one user at a 

to many users without ^^^^"^ programming the web server 

time profile management controls access oy prog access 
! / flpnv access to applets. The web server enforces the access 
to permit / deny access to v*^ ^^„^<.rted bv the webserver 

control The profile manager servlet is also protected by 
control. .11"= t"- „„_j t« webserver for 

• • « „cpr ID'S and passwords to be passed to the weosei. 

Sor user passwords as reqoirea. 

Pi, 5 Shows th. svste. o£ Fi,. 2 in .or. detail co.£l,.r=t»on 
. ,.tl IS .nvokea by the .amlnistrator «ithi» the profile 
" „rt wo °. '^PPletl »ay i.ple„e»t the application pro,ra„ 

management tramewoi^ ^.v^nnt its operational 

^ ^ /AOT^ 515 for Querying information about its up 
interface (API) 515 foQ^^ context changed events, query access 
environment (eg., y^^^^^^ ^^^^^ ^^^^^^^^^ ,i,^tly withm the 

ragint r^me or. — on. 

configuration applet. In any event. ,,„^^n loadO. and saveO 

^ .V, v,= = -ir. API methods: enablePersistence ( ) . ioaa u . 
understand the basic API mecn Prooerties object used to 

► vfi<;ic methods of a ^ava.util. Properties <-,«j 
in addition to the basic metnoa util .Properties object. 

,et preference ---;--,rs^:i;: O^I die ^0 methLs. Appletl 
30 API SIS Class and call 

need only register ^^^JZe The loadO method can be called to retrieve 
these methods as appropriate. The loa u configured in 

eor^^ State of preferences for the user applet being 
Z ::::::: :rruser or group selected by the ^^-^ them 

- ^--n-ronfirur::::^ :;:rLrc:ran:rp::vrden;\h. appiet .hich 

using the -^^^^^/^^^-^^ ProfileMana.ementProperties object. 

uses the ; ,,3t of user applets authorized for access 

similarly, .f appietl ^^^^.^ ^.^^ ^^^^ 

' ""';he getcontext () method can be used by the applet to display the 
,0 server^ "^^^^^ext .at it is running in or even to ensure that it only 
name of the ^ ,i e . if an applet wanted to configure a 

runs in a certain context (i.e.. it .^^^^^ 

■^^ or, the server using the export agent, it might oniy a 
service on the server ^» miration being exported, 

to be run. at the Aliosers context since ^^^^ ^^J^'^^l'^'^;^^^^, to run in 
,5 is server specific as opposed to user specific. For applet 
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the profile management framework, all that is required is for the applet 
to register with Prof ileManagementProperties 410 and implement the 
Prof ileManagementProperties class, an extension of the ^ 
java.util-Properties class. 

The profile manager 506 also provides a context change API 516 for ■ 
configuration applets. Appletl may implement a context change event 
listener 512. The API 516 and the event listener 512 allows the 
administrator to change contexts (user or group) while running the 
configuration applet, without having to stop and restart it. For example, 
when configuring applet user preferences, the administrator will likely 
change contexts many times during the configuration. If the configuration 
applet is registered as a listener to such events, profile manager 506 
will notify it of a context change via API 516, This allows appletl to 
refresh its preferences from the server for each new context. without the 
event listener API, appletl would have to be terminated by the 
administrator and restarted after a new context has been selected to 
reference the existing preference information for the new context and 
avoid being stopped and restarted by the Profile Management applet. To 
register, appletl calls a method on its properties object 
Prof ileManagementProperties 510 i.e., addContextChangeListener (API 516) 
to register itself. when the administrator sets a new context, profile 
manager 506 performs a set context call (API 516) to object 510, which in 
response calls the reload method (API 516) on event listener 512. Event 
listener 512 now performs a load properties call to its properties object 
510 to get the new preference data from the server for the new context, 
and causes appletl to updates it GUI and internal variables to reflect the 
new preference information. 

The above functionality avoids the possibility of a network 
administrator reeding data from one context, changing context, and 
accidentally overu^riting with a saveO when intending to load () before 
making configuration changes in the new context. 

Applets that do not register es listeners will be stopped, 
destroyed, relopdec, end restarted by the profile manager applet when the 
administrator forces a context change. 



The profile management also provides a "properties export" service 
to allow the easy retrofitting of existing hardware and software into this 
profile management environment. The properties export service allows 
profile manager 514 to support user workstations (the physical hardware) 
as well as users, groups, and user applications. Since existing 
workstations do not )cnow about Prof i leManaaementProperties 510, the export 
service allows workstation vendors to create workstation-configuration 
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applets that specifies an export agent 520 to be invoked on the server 
v^hen the vendor applet saves it preference inf orination. The export tag 
causes an instance of a vendor- supplied class (the export agent 520 
object) to be created and the export method to be invoked on the object to 
specify that workstation configuration information be saved in whatever 
proprietary file format and/ file location (s) that ar^ required by the • 
workstation being configured. 

Assume that appletl is the configuration applet provided by a vendor 
for an existing terminal that is incompatible with the present profile 
management system. The vendor also supplies export agent 520. An 
administrator can configure the terminal for operation in this system by 
running profile manager 506, set the context to the terminal being 
configured, runs the vendor supplied configuration appletl and configures 
15 the applet, when the administrator saves the configuration, part of the 

information that is transmitted to the server is a unique identifier that 
identifies the terminal being configured. Typically, this is the Media 
Access control (MAC) address of the terminal. Profile manager servlet 514 
detects that an export agent is specified on the save. Profile manager 
servlet 514 detects this from one of the preferences being saved that 
specifies need for the export agent. The preference specifies the export 
tag in the form of a key value pair of 

XXXXEXPORT_AGENTXXXX= {fully qualified class name of export agent) 

The Export Agent's export (Context context, config properties) method 
is called by the profile manager servlet 514 to create one or more files 
522 on the server from the save preferences information. The specific 
file or files are identified by the unique identifier of the terminal that 
came with the properties information from appletl. when the terminal^ 
later boots up, it uses its unique identifier to locate and retrieve its 
configuration information from files 522 on the server in the same manner 
that it always did, independent of the profile management system. 

Figure 6 illustrates an applet2 running on a client computer. 
>pplet2 might be an end-user applet such as a word processor. In any 
event applet2 has access to some of the same API methods as shown at 515 
of Fig 5 if it desires. Applet2 uses the load method to retrieve 
preferences and the save method to save any preferences that might be 
changed by the ^nd user. EnablePersistence initializes the Profile 
Management Properties object for applet2 with context equal to the user 
and oenerates the unique key for identifying the preference information 
storage location on the server, as described above relative to the 
administrator. 
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Fig, 7 shows the situation of a user bringing up his or her desktop. 
The user on the client (700) points his or her web browser at the URL of 
the desktop applet on the server and at step 704 sends k message 
http: //server/Desktop. html) . Since Desktop.html is a file that the server 
protects, a challenge is sent back to the web browser on the client at 
706. The web browser on the client responds by prompting the user for a 
user ID and password. The client then sends the user ID and password 
information to the server at 708. The user ID and password are shown in 
bold at 708 of Fig. 3 to illustrate that this information is passed by the 
web browser itself. This type of nomenclature is used in other places to 
illustrate the same thing. Since, presumably, the user has permission to 
run the desktop applet, the request will be honoured. 

There are a series of interactions between the client and the server 
(not shown) where the code for the desktop applet is loaded to the client 
from the server. The desktop object is created and begins to execute at 
712. The desktop object needs its preference information (i.e., 
configuration information) so it can tailor the desktop for the end user 
who is invoking it. To this end, as part of the desktop object's 
initialization process, the desktop creates a Prof ileManagement Proper ties 
object P at 714, which is used to load, , get, cache, set, and save a 
copy of the user's preference information from the server for the desktop 
applet. The desktop object then performs an API call 

p.enablePersistence (desktopObject (applet)) at 716, which, at step 1) of 
716, initializes the Prof ii eManagementPropert ies object P with the URL of 
the profile manager serviet 214. This URL is derived from the URL of the 
desktop applet that was loaded from the server previously. The 
Prof ileManagementProperties object P sends a request 718 to the profile 
manager servlet 214 to get the context for the user running the desktop 
applet, in this case, the context consists of two components, a context 
name which is the ID of the user, and a context type which in this case is 
user. The profile meneaer servlet gets the ID of the user from the request 
718 and returns the user context at 719. At step 2 of 716, the 
Prof ileManagementProperties object P is initialized with the context of 
the user running the desktop- At step 3 of 716, the 

Prof ileManagementProperties object P genereces a unique key for the 
desktop software by asking the Java desktop object P for its fully 
qualified class name. All Java objects know their class name. This unique 
key is combined with the user's context information to provide a parameter 
that specifies a unique location in the database 212 for storing the user 
specific preference information for the desktop applet. Any desired 
method can be used for mapping the string consisting of the fully 
qualified class name and the user context information into the data store 
location . Next, a request 720 is sent to the profile manager servlet 
214 to get the preference information, tailored for the user, for the 
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Desktop applet. The context and key are passed as part of the request 720 
to identify the requested preference information. The profile manager 
servlet 214 responds with the requested preference information at 722. 
which is cached in the Prof ileManagementProperties object P 604. 

continuing on at Fig. 8. at 800 the Desktop objpct reads it's 
preference information out of its Prof ileManagementProperties object P. 
and begins to update the desktop accordingly (i.e.. it might --^f^ 
screen colour to blue, get information about the posxt.on of icons, etc.) . 
The desktop object calls a method on its Prof ileManagementProperties 
object P to get a list of the software to which the user has access 
r,.=rmission The Prof ileManagmentProperties object P requests the 

™ : fen I soa ..o» ..e pro.Ue „,».,er serv.et 2» ^^-""J ' 

r.soons. with the r^uestea information at B0< . For each such appl« to 
^hich the" er ha. aoce.s, the information inclua.s a „ser frienaiv n-, 
thi applefs URL, the URL of an icon for the applet, etc. <"''°'"""" 
thtt i! required for the aeslctop to represent the applet on the desktop 
ana to load and launch it, . and other optional material which iS not 

- =r„- tn the invention. This information is stored in the 
reaevant to the mventio returned to the desktop object, 

prof ileManagmentProperties obDect P, and return 

;,t 806. the desktop object uses theapplet information to build a foloer 
Tor thi applets and to generate a window displaying the icons and the 
friendly name for each applet to which the user has access. 

;.ssume that in a previous run of the desktop by the 
.....ed and dropped the -ons for some 

rLrLrs Splet: :Lr;::e dragged and dropped from the 

rol^r o th de k op^ However, these desktop objects normally would be a 
oar of the users preferences that were saved during the last run and 
wouid still be displayed on the desktop . To avoid this situation the 
would still be oisp >^ prof ileManagmentProperties 

aesktop ---"^^J^^;; ;!" thaf are configured to appear outside of the 

:ZZ:TZ:Z^ ~ fonowing procedure would be looped for 

Tach sLh applet'' .t step 310 the desktop checks ^ol 
appearing outside of the applet window against the list of applets from 
appearing ^^^^^ ^^^^^^ appears m the 

rilt^^::: i on^ -Plet is Placed on the desktop at 310 in the s^e 

liat, tne ic ^^^^^^ applet, the 

rp:::ns".mred »oI X: desktop. = preferences at step .1. ».d removed 
frol thi ProfllLnanmentProperties oWect P. Xt^ inv applets are removed 
a ;art Of th s process, the desktop tells the Prof ile««,a^ntProperties 
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object P to save the preferences at step 816. The 
Prof ileManagment Proper ties object P sends a request 818 *with the 
preference, key, and context information to the profile manager servlet 
214 to save the new preferences information in the Database 212. The 
server sends a response 820 to the Prof ileManagmentProperties object P 
informing the Prof ileManagmentProperties object P that the request was 
successfully .completed. 

Fig. 9 illustrates the situation of an administrator running a 
configuration applet to configure preferences for an applet for other 
users or groups of users. It is understood that the principles discussed 
here also apply generally to the configuration of terminals or groups of 
terminals. The administrator on the client 900 points his or her web 
browser to the URL of the profile manager applet 214 on the server, which 
is to be run. The URL is sent to the server at 904. Since 

ProfileManager.html is a file that the server protects, a challenge 906 is 
sent back to the web browser on the client. The web browser responds by 
prompting the administrator for a user ID and password. The request to get 
profileManager.html is then repeated at 908 to the server with the user ID 
and password information included in the message. Since presumably the 
administrator has permission to run the profile manager, the request is 
honoured and a profile manager applet is downloaded to the administrators 
terminal at 910. There are a series of interactions between the client 
and the server (not shown) where the code for the profile manager applet 
is loaded to the client from the server. The profile manager object is 
created and begins to execute at step 912. 

A Prof ileManegementProperties_nonContextFloating is used by the 
profile manager instead of a normal Prof ileManagementProperties object.. 
It has the same behaviour as a Prof ileManagementProperties object with one 
exception: when preferences are loaded and saved, they are loaded and 
saved to and from the context of the administrator who is running the 
profile manager, as opposed to loading and saving to and from the contes^t 
(i.e., user or user group) for which the administrator is configuring. 

The profil,e jnaneger object needs its preference information (i.e., 
configuration information) so it can tailor the profile manager for the 
administrator is invoking it. To this end. as part of the profile manager 
object's initialization process, the profile manager creates a 
Prof ileManagementProperties_nonContextFioat ing object P_NCF at step 914, 
which is used to load, get, cache, set, and save a copy of the 
administrator's preference information from the server for the profile 
manager applet. The profile manager object then calls 

p_NCF.enablePersistence (prof ileManagerObject (applet)), which in step 1 of 
916 initializes the Prof i leManagementProperties_nonContextFloat ing object 
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P_KCF with the UHI. Of the profile manager servlet 214. This URL is derived 
from the URL of the profile manager applet. The 

ProfileManaoementProperties_nonContextFloating object P_^CF sends a 

IITIib\o the profile manager servlet 214 to get the context name 
mi Z alinis:rator and the context tvpe ,USB. . - — 

3erviet gets X:::: ^^^^^ ^^^^ 

Object P NCF. The ProfileManagementProperties_nonContextFloatxng object 

is'initialized with the context of the administrator runnxng the 
^r^r^^f^t at stBD 2 of 916. At step 3 of 916, the 

pfof!;e"nare-ntProperties_nonContextFloating object P_NCF generates a 
unique key for the profile manager applet by asking the Java 
profilemnagerobject object (passed as a parameter an the 

• . ^aii^ for its fully qualified class name (i.e., 

rori!::"rg fo e :"Lcras:n.get.L()). This unique key. confined with 
Te ^inistrator.s context information, is mapped to specify a un.que 

location in the database 212 for the administrator's specxfxc preference 

information for the profile manager applet. 

^ request (922) is sent to the profile manager servlet ^14 to get 
.ne preference information tailored for the profile manager applet as 
confloured for the administrator. The request (922) --^"^-J^J 
appropriate context name and type and key information to 

^^onr-ate preference information. The profile manager servlet 214 
appropriate preferenc ^^^ference information (924). which is cached 

responds with the requested preference mx^. 

ilthe ProfileManagementProperties_nonContextPloating object P_NCF. 

profile manager reads its preference information f 
ProfileManagementProperties_nonContextFloatinc and updates itself 

^ r^niv (i e sets its background colour to blue for example) . 
accoramgly ti.e.. seus, j-uo 

^r. Pir, 10 The profile manager requests the 
Operation continues at Fig. lu. ine yiu ■=> 

■^.A^r. „=pr<? user groups, and software from the 
infonr.ation about existing users, user gro p 

profile inanacer servlet 214 and builds the tree m the left panel of t 

Tro le .ana;ers configuration window at 1002. See ^^^^ 

for examples of the administrator's left panel. At this point 1004, tne 

Tdli s^alL selects a oes.red context for configuring -V clicking on a 

user or aroup from the left panel tree. The profile manager sets the 

context for Prof ileManagement Properties objects by calling ■ 

P K F etContext(selected context). See Fig. 13 for a elected contex of 

•user croups'. ..hich refers to the group of all system users or to Fig. 

18, Where a group context of 'Development' is selected. - ^° ' 

..ere a user context -colleend. is ^ ;or .Ti^ 

an ;xample of selecting an applet. 
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At Step 1008, the administrator then clicks a Run/Customize button to run 
the applet selected for configuration. This applet might be a separate 
configuration applet for an end user applet, or it might be the end user 
applet itself. The selected applet is requested and loaded from the 
Server at 1009 and 1011. At step 1010, the configuration applet object is 
created and begins to execute and to generate its 
Prof ileManagementProperties object P. 

If it is assumed that the applet is a separate configuration applet 
for an end user applet, then at step 1012, the applet calls 
p. enablePersistence (conf igAppletObj ect , 

f ullyQualif iedClassNemeOf AppletBeingConf igured) . On the other hand, if 
the applet is a user applet, rather than a separate configuration applet, 
the call would be p . enablePersistence (endUserAppletObject) since it wants 
to configure its own preference information as opposed to the preference 
information for another applet. The current Context is already known by 
the Prof ileManagementProperties object P since it was previously set by 
the administrator via the administrator's 

Prof ileManagementProperties_nonContextFloating object PM_NCF, The location 
of the profile manager servlet 214 was previously generated when 
enablePersistence was called on the Profile Managers 

Prof ileManagementProperties_nonContextFloating object PM_NCF. In the case 
of a configuration applet, the unique key for the applet does not need to 
be generated because it is passed by the configuration applet to the 
Prof ileManagementProperties object P in the enablePersistence call. 

At step 1014, the configuration applet registers itself with its 
Prof ileManagementProperties object P as a context change listener. As 
discussed earlier, this allows the applet's Prof ileManagentProperties 
object P to notify the applet if the administrator makes a context change 
so that the applet can load the preference information for the new context 
and update its Graphical User interface to reflect the new configuration 
information, without requiring that the applet be terminated and 
relaunched in the new context. 

Operation continues at Fig. 11. At step 1104, the conf igure t iorj 
applet tells the Prof ileManagementProperties object P to load the 
preferences from the current context for the applet being configured. A 
request 1105 is sent to the profile manager servlet 214 to get the 
preference information, tailored for the context previously selected by 
the administrator, for the applet being configured. The request 1105 
includes the appropriate context name (the context the administrator has 
selected) and the context type (USER, USER_GROUP, or ALL_USERS_GROUP as 
appropriate) and key information to specify the location of the 
appropriate preference information. The profile manager servlet 214 
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w^tb the requested preference information at 1106, which is 

Tppltt cat. pre£««ces £r»» the Prc£ne».n„e»e„t,.roperties 6bje=t P ana 
„paatas'its Oraphical us^ar Interfac. accordingly. 

Tne a*.ini=trator configures the applet at 1107 ant, .aves the . 
The a™ .,.„Die by clicking a SAVE biltton provided by 

modified preferences or exa„pl y^^^^_^^ the configuration applet calls 

' .o „«hod rits Pro£ile«ana,e„entProperties object p. The 
the saveO method on its preferences and the unique 

P.o£ile„anage»entProper .e. ob e P send 

::rr::rc::tr r:r::iie\a„ager seryiet .1. .^^^^^^^^^^^ 

servlet stores the preference information m the database 212 xn 
location specified by the Context and the key. 

.tep iios is an ..a„pie of -^;rn::::"°'.hnd^.Ts:rat:r""' 
irii'ctr: rr-rby-s::!:: r^user cr'us„ .oup 
-Tt-fihr—.:;-^^^^^^ 

P_NCF.»etcontext<=electe reload properties 

notify event listener 512 ,^,„t listener 512 

515. = "tr et 'the Pr ferences for the new content and 

5 per£or:.s a lo.dO "I' J.I L new preferences at step 1118. The 

°'s:r.t:r"arn:: pro "a modify the preferences for the new 
:::: des"ed, ana to save the. if required and then to proceed on 

"th a ;ew context change if necessary as described above. 

The regaining figures 12 through 24 show actual screen snapshots of 
en .aministrator.s worHstation while running portions of the profile 
manager 206. 

• ^«r,f i aura t ion window 1200 is shown in Figure 12. The tree 
.ne ma.n conf gur t on ^^^^^^ ^^^^^^^ profile management 1204 

.,ew ,,,,,,,-,e on the server. When this item 1204 .s 

as one of several servac ^^^^ ^^^^ 

selected as shown m Fig. 12- tne rig y -ervice Expand and 

displays a welcome message for the profile management service.. Exp 
displays a e . .-nft are used to control the appearance of 
40 contract icons such as 1208 are usea uo 

.s called an expand .^i„i3„ator can display thee, sub- items by 

in::::: ZT:Z..^ which wm then beco^...- -tract icon. 

45 (•-')• 
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Fig. 13 illustrates an expansion of the Profile management item 1208 
in Fig. 12, which results in the display of three default sub- items in 
Fig. 13 - 'Applets' 1300, 'User Groups' 13 02 and 'Users* 1304. Expansion 
icons indicate that these items can also be expanded. 'Applets' 1300 
allows the administrator to define the user applets available on server 
202, 'User groups' 1302 allows the administrator to create and populate 
the user group tree of Fig. 3 and to set group preferences. 'Users' 1304 
allows the administrator to create new users and to set their preferences 
or to change preferences for existing users. In the example of Fig. 13 
'Applets' 1300 is selected, when this item is selected, panel 1305 on the 
right of the window displays a list 1306 of user applets that have already 
been defined to the system. Attributes of the application that is 
selected in 1306 are shown at 1308. The administrator defines a new 
applet by selecting <NEW> in 1306 and entering the name and location 
information requested in 1308. An existing applet 'Database Explorer' is 
shovvTi selected in 1306. At 1308, the 'Applet name' field displays this 
applet name. The 'URL' (Universal Resource Locator) field displays the 
Intranet or Internet web address of this applet on server 202. The field 
'Complete path of html file' displays the directory path and file name of 
the applet in the disk directory structure of server 202. The field 
'Fully qualified class name' displays the fully qualified class name of 
the applet. The field 'Icon URL' displays a web address of the image file 
used to generate an icon for the applet on a users desktop. The remaining 
fields are for optional information that may be required by the software 
upon invocation. A command button 1310, 'import Applet List from File', 
allows the administrator to append definitions of applets to the existing 
list 1306 from an existing text file. when button 1310 is clicked, the 
window shown in Fig. 14 pops -up and allows the administrator to enter the 
path and file name of the text file containing the applet definitions to 
be appended. To save all pending changes, the administrator clicks on 
File 1312 and then Save (not shown) . 

In the left panel, the User Groups item 1302 corresponds to the 
AllUsers group of Fig. 3 ('User Groups' and 'AllUsers' are used 
interchangeably herein). Fig. 15 shows the right panel of the 
administrators station when the 'User Groups' item 1302 is selected. In 
Fig. 15, a notebook panel is displayed on the right that contains three 
tabs - a Members tab 1514, a Subgroups tab 1516 and an Applet Permissions 
tab 1518. The Members tab is selected in Fic . 15. The Members panel 
contains a list 1520 of the log-on identifications of all members that 
have been defined to the system. To create a new user (who will 
automatically gain membership into the presently selected group context - 
'User Group'), the administrator selects <NrEW> from the list 1520, enters 
the appropriate information in the entry fields 1522 to the right of the 
list, and then clicks on the Create button 1522. when an existing member 



wo 99/57863 



26 



PCT/GB98/03866 



is selected from the list 1520, the attributes previously saved for that 
"er are displayed at 1522. These attributes include the full nan.e of the 
selected member, the member's system ID. password and any desired 
or,.s The attributes, except ID, may be edited and the changes 
5 ft d (bu nL saved) by clic.in. the Modify button 1524, or the user 

' ::rb emoved from the system entirely by clicking the Delete button . 
1526- Any pending change may be removed by selecting tihe entry xn the 
list 1520 and clicking the Undo button 1528-t- 

Pig 16 Shows the administrator's right panel that is displayed when 
the Subgr;ups tab 1516 is selected. Subgroup list 1620 shows -i^^^-^ 
'roups that are subgroups of the item selected in the left pane . which xs 
^User Group, in this example. Therefore, list 1620 displays all immediate 
subgroups of the 'AllUsers' group, m the left panel, 'User Groups is 
ZTfa The subgroups shown in list 1620 are also the expanded items 
::rr user Groups' in left panel. In list 1620. a status field shows the 
resent titus of each subgroup, such as 'I delete'. 'I Modify', and ': 
create' L empty status field in list 1620 indicates that the subgroup 
llTsTs and no actions are pending to be saved. The ' syn^ol indicates 
.0 Th t he tatus is pending (not yet saved) . Attributes for the subgroup 
selected in list 1620 appear in 1622. These attributes include the 
subgroup na.e and desired cononents about the subgroup. To create a new 
subgroup ^^^^i^^.^or selects <NEW> from list 1620. enters the 

subgroup, the ammistra clicks the Create button 

subcroup name and desired comments m 1622. and clicks tne 
1628 L entry of '! create <subgroup name>' then appears m list 1620 
as a'pe^din. action, to save all pending changes, the administrator 
Clicks the File button in the top menu bar and then Save (not shown) . 

Kic. 17 Shows the right panel that is displayed when the Applet 
^=.K mifi is selected. List 1720 shows all names of all 

the staws aepicted is . =h=,,,e that is pana>», a save. In Fig. 17, the 
ToZ Zlr =^c„ps. is s.lectea in th. tree she... in the left panel, vhich 
groop user P j„ si„„ Ul »sers o; 

ZZ:T::Z:ZJ^rZ. l.. .user =roi.ps. group, list >"0;^-= 
^roblfaefault permissions for .11 syste. os.rs for "=» ^-^^"/f " 
the system. For example, the aefanlt permission status for applet 
" ZZTs. Bxplorler. is .permif leaning access is ^^^^sers 

:rre;;:e«™":na:rs:rror'r"»ge 

*-o snnlet TFTP IS 'deny (access is ociiJ-cw/ . 

the pei^ ssicn status of an applet_hv selecting it in list.J720 ana 
45 S!=ri»g tie -permit group access, hutton 1730 or the -Deny group access 
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button 1732. Furthermore, regardless of an applet's permission status for 
the selected context, an administrator can select an applet from 1720 and 
click the 'Run/Customize' button 1734 to execute the usfer applet under the 
selected context. The panel region previously showing the notebook for 
the current context then becomes occupied by the executing user applet. 
If the user applet happens to be a configuration applet for other 
software, the administrator can then save software preferences (through 
the configuration applets unique facilities provided for this function) 
which will then be saved as the software's default preferences for the 
selected context. If the applet is an end user applet, the functions are 
the same, except the end user applet loads and saves it own preferences 
rather than preferences for a separate piece of software. 

Fig. 18 shows the complete expansion of the administrators left 
panel subgroup tree beneath 'User Groups' immediately beneath 'User 
Groups', there are two subgroups 'Administrators', a default subgroup that 
cannot be removed, and 'IBM', a subgroup defined by the administrator. 
The 'IBM' subgroup has also been expanded and contains three subgroups 
'Hardware', 'Services' and 'Software'. The 'Software' subgroup has been 
expanded and contains at least one subgroup called 'Development', The 
'Development' subgroup contains at least one subgroup called NCoD. 
Subgroup 'NCoD' contains a number of subgroups, such as ConfigFW 58, which 
have no children. Also in this example, subgroup 'Development' is 
selected in the expansion tree. Since 'Development' is not at the top of 
the tree hierarchy (the 'All Users' group), the notebook shown in the 
right panel is somewhat different from that of Fig. 15 when 'User Groups' 
was selected, because all users are not automatically a member of 
'Development', as they are of 'User Groups'. The list 1820 displays the 
log -on system IDs of all system members. The status beside each user ID 
in list 1820 shows whether the user owns a membership in the 'Development' 
subgroup. A status of 'yes' indicates that the user is a member of the 
'Development' subgroup, 'no' indicates that the user is not a member of 
the 'Development' subgroup, and 'inherited' indicates that the user 
inherits membership within the 'Development' group by belonging to at 
least one of Development's subgroups further down the tree. A user's 
membership status for a subgroup is modified by the administrator by 
selecting the user in list 1820 and then clicking on the 'Add to Group' 
button 1836 or 'Remove from group' button 1838. If the administrator 
wishes to create a new system user, or modify or delete an existing 
member, the administrator clicks on the 'Create/Modify/Delete Users' 
button button 1840. This action brings up the notebook page shown in 
Fig. 19. The right panel of Fig. 19 is similar to that of Fig. 15 and 
allows the administrator to create a new system user by selecting NEW in 
list 1920 and then clicking the 'Create' button. Similarly, the 
administrator can modify or delete an 1Sc iTt ing system user by selecting 
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the appropriate user in list 1920 and clicking the appropriate button 
•Modify or 'Delete'. Users created at any subgroup context (e.g.. 
'Development') not only gain the required men^ership in 'User Groups' . but 
are automatically made members of the selected subgroup. Changes to the 
system user list are saved by clicking on 'File' in the top menu bar of 
the right panel and then clicking 'Save' (not shown). ^ 

Fig 20 shows a direct way to get to the system user list for 
editing, rather than through the group and subgroup route shown in Fig. 
19 TO get to Fig. 20. the administrator selects 'Users' 1304 in the_left 
panel of Fig. 13. for example. Then in the right panel shown m Fig. 20. 
the administrator can create new users and modify and delete existing 
users, as already discussed., without being in the context of a group or 
subgroup . 

m Fig. 21, the administrator wishes to work directly on information 
corresponding to a user whose ID is 'colleend'. To do this the 
Administrator expands 'Users' in the left panel of Fig. 21. for example, 
and then selects 'colleend'. as shown. The right panel then appears, 
which is devoted to colleend' s system information. The right panel 
contains three tabs. The first tab 'User Information' is selected by 
I^fault. xn this tab. the administrator can modify the name. ID. passworo 
and comments pertaining to colleend. 

Fig. 22 shows the right panel when the administrator selects the 
second tab 'Group Memberships'. List 2220 shows all subgroups of which 
^oneend is a meLer. The subgroups are shown in this list in the order 
of subgroup priority for colleend. The administrator can change 
colleend' s subgroup priority by selecting a subgroup and using the up anc 
Itl arrows to the right of list 2220 to move the selected subgroup up or 
TZ the list as desired, if the administrator clicks the 'lT^l\^^ 
Group Men^erships' button 2242 in Fig. 22. the right ^^^^^^^^/^f J^^'^^^ 
contents of Fig. 23. The Fig. 23 right panel allows the administrator to 

the sJgroups of which coneend is a member. The ^^i^i™ 
does this by clicking on an appropriate box corresponding to a desireo ^ 
subgroup. If the box is clear (meaning that colleend is not presently o 
member), then a checK mark is added to the box to include ^^^^^^ /^^^^^ 
subgroup. conversely, if a subgroup box is already checked, then clicking 
on the box Clears the check mark and removes colleend from the subgroup. 

Fig. 24 sLows the right panel when the Applet Permissions tab of 
Fig. 22 is selected by the administrator. in this right panel, list 2420 
displays all applets that are defined in the system. "^^Y*^^""^"^^"^^^^ 
can permit access by colleend to an applet by_.selecting_.the applet m list 
2 20 and then -cTTcking- the " ^Permit user access' button 2430; or access can 
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be denied to colleend by clicking the 'Deny user access button' 2432. The 
administrator can also launch an applet in the context df colleend by 
clicking the 'Run/Customize' button 2434. when this is 'done, the applet 
selected in list 2420 is launched in the right panel. The administrator 
can then modify any preferences that the applet allows and save the 
preferences in the manner provided by the applet. A typical scenario here 
is for the administrator to launch a configuration applet then to fill in 
a variety of preference fields. However, if a separate configuration is 
not provided for a user applet, the administrator can launch the user 
applet in the context of a user and set preferences from the user applet. 
A typical s'cenario here is for the administrator to select a group or user 
context and then to launch the user applet as described above. The 
administrator can then typically modify preferences from an options menu 
and save them in any manner provided by the user applet. For example, 
typically, the user preferences are saved when the options dialogue is 
closed, or the user applet may provide other methods of saving the 
preferences. In any event, since the administrator is running the applet 
in the context of colleend in this example, the preferences set up by the 
administrator through the user applet are saved on the server as if 
colleend had entered them directly herself by running the applet. 

Not shown in the figures is a scenario whereby a user can modify 
some preferences that pertain to a user applet. For example, a user 
applet may allow a user to select a window background colour or fonts and 
font sizes, so that each system user can individualize the applet to some 
extent when the user applet executes on the users desktop. In this case, 
the user modified preferences are saved in the same way as they are when 
the administrator runs the user applet. One difference, however, is that 
the administrator can run user applets to set preferences in group 
contexts, whereas users can only affect preferences for their individual 
context . 
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1 m a network system comprising a network interconnecting a server 

and a plurality of user stations, a method of managing desktops on the 
user stations from the server, wherein the server stores a plurality of 
user applications for downloading to user stations, anA further stores 
access permissions for the applications for each user, said method 
comprising steps of: 



receiving at the server a log-on request including a user identifier 
from a user station; 

using the identifier to build a list of applications for which the 
15 user has access permission? 

dovmloading to the station the list of applications for which the 
user has access permissions; and 

displaying on a portion of the desktop objects corresponding _ to each 
application in the list, said objects when selected by the user bexng 
operative to request a download of the corresponding application to the 
user station. 



25 2. 



The method of claim 1 further comprising steps of; 



using the user identifier to built an icon on the desktop that 
represents a user application specified by the user at an earlier txme; 

for each user desktop icon specified by the user at an earlier time 
that corresponds to a user application, checking the access perm.ssxon for 
the user to the user application; and 

fitting from the desktop any such user- specif ied icon — -^^^^"^ 
to a user application to which the user does not have access permission. 

in a network system comprising a network interconnecting a server 
'and a plurality of user stations, an apparatus for managing desktops on 
the user stations from the server, said apparatus comprising: , 



n^eans for! receiving at the server a log-on request including a user 



40 i 
means fori 
identifier from a user station: 

means for using the .identifier .to build..a lis.t.of applications for 
45 which the' user has access permission; 
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means for downloading to the station the list of applications for 
which the user has access permissions; and i 

means for displaying on a portion of the desktop objects 
corresponding to each application in the list, said objects when selected 
by the user being operative to request a download of the corresponding 
application to the user station. 

4. A computer program product stored in a computer readable storage 
medium for, when run- on a computer, carrying out in a network system 
comprising a network interconnecting a server and a plurality of user 
stations, a method of managing desktops on the user stations from the 
server, wherein the server stores a plurality of user applications for 
downloading to user stations, and further stores access permissions for 
the applications for each user, said method comprising steps of: 

receiving at the server a log-on request including a user identifier 
from a user station; 

using the identifier to build a list of applications for which the 
user has access permission; 

downloading to the station the list of applications for which the 
user has access permissions; and 

displaying on a portion of the desktop objects corresponding to each 
application in the list, said objects when selected by the user being 
operative to request a download of the corresponding application to the 
user station. 
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